@tomrndom
The fix addresses the bug for one data path (entity-level items from getSponsorManagedForm) but leaves the same bug active on the individual-item edit path (currentItem from getSponsorCustomizedFormItem), meaning images will still be silently dropped in the most common editing scenario. The missing regression test also means the fix is unverified.

@tomrndom
Add a unit test for RECEIVE_SPONSOR_CUSTOMIZED_FORM in sponsor-customized-form-reducer.js covering: items with images (file_path mapped), items with no images, and empty items array

@tomrndom
DEFAULT_ENTITY missing items field
fix: Add items: [] to DEFAULT_ENTITY

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Add a test for items where images is missing (not just empty).

You already validate images: [], but the reducer also handles images being absent. A direct test for that case will lock the intended fallback contract.

   it("handles items with no images", () => {
@@
     expect(result.entity.items[0].images).toEqual([]);
   });

+  it("handles items with missing images field", () => {
+    const result = sponsorCustomizedFormReducer(DEFAULT_STATE, {
+      type: RECEIVE_SPONSOR_CUSTOMIZED_FORM,
+      payload: {
+        response: {
+          id: 1,
+          code: "FORM1",
+          items: [{ id: 10, name: "Item A" }]
+        }
+      }
+    });
+
+    expect(result.entity.items[0].images).toEqual([]);
+  });

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/reducers/sponsors/__tests__/sponsor-customized-form-reducer.test.js`
around lines 58 - 93, Add a new unit test that dispatches
RECEIVE_SPONSOR_CUSTOMIZED_FORM to sponsorCustomizedFormReducer with a payload
whose response.items contains an item object that omits the images property
(e.g., { id: 10, name: "Item A" }), and assert that
result.entity.items[0].images is an empty array; use the same DEFAULT_STATE
setup and naming pattern as the existing tests to ensure the reducer's fallback
for missing images is validated.

This block (the RECEIVE_SPONSOR_CUSTOMIZED_FORM_ITEM path) has no tests, unlike the form reducer which got full coverage in this PR.

The file_path normalization here is the path that populates currentItem, which is what SponsorFormItemForm receives as initialValues — it's the edit-form image fix. Consider adding a test that asserts currentItem.images[].file_path === file_url, covering at least the images-present and images-absent cases.

This PR defensively added (item.images || []) on line 113, but item.meta_fields on this line is still unguarded. If the API returns an item where meta_fields is null or undefined, this throws a TypeError and breaks the form-open flow.

Suggested fix:

meta_fields: (item.meta_fields ?? []).length > 0 ? item.meta_fields : []

Two different action creators dispatch RECEIVE_SPONSOR_CUSTOMIZED_FORM into this case with different API expand contracts:

• getSponsorManagedForm expands items.images, so the normalization below runs correctly.
• getSponsorCustomizedForm does not expand items, so payload.response.items is absent and falls through the || [] guard safely.

This is safe today, but worth documenting — a future developer adding item-level display to the customized-form popup may not notice that items are empty in that path. Consider a comment here or splitting the action types to make the contract explicit.

No test file was added for this reducer, while the form reducer received full coverage in this PR. The three cases most worth adding:

• RECEIVE_SPONSOR_CUSTOMIZED_FORM_ITEM with images — asserts currentItem.images[].file_path === file_url (the actual edit-form path this PR fixes)
• RECEIVE_SPONSOR_CUSTOMIZED_FORM_ITEM with meta_fields: undefined — proves the unguarded .length access on line 117 does not throw
• SPONSOR_FORM_MANAGED_ITEM_UPDATED — verifies that list images survive a save round-trip (currently stores updatedItem.images without file_path normalization, which is fine for table display but worth locking in)